Freaks Macintosh Archive/Freaks Macintosh Archive.bin/Freaks Macintosh Archives/Textfiles/zines/hir/hir3 Folder.sit/hir3 Folder/HIR3-5.TXT

Text File | 1997-12-29 | 11KB | 210 lines

*-<<{([<{([<{([<{([<{([<{([<{([<{([ H i R ])}>])}>])}>])}>])}>])}>])}>])}>>-*
|    Fun With UNIX I, The First of a series dealing with neat UNIX tricks   |
*-<<{([<{([<{([<{([<{([<{([<{([<{([ H i R ])}>])}>])}>])}>])}>])}>])}>])}>>-*
                                   By Axon

This is the first article in a series of god knows how many that will be
dealing with some fun, but usually harmless (and always just pure evil)
tricks that can be performed under various flavors of the UNIX operating
system.  These tricks may not work on all flavors, and may not even work
the same with 2 different machines running the same operating system. It
has a lot to do with how the administrator has configured things. Enough
with the small talk, I think it's time to go out and have fun with UNIX!

This Article, of course assumes that you have a shell account on a unix
box, somewhere in the world.  It's also nice if many other people have
accounts on that box, too, otherwise some of these unix fun tricks wont
seem very fun, because you'll have no one to screw with or spy on.

Compatability note: I really do not know what flavors these work on.  I tested
and discovered these fun tricks on an IBM (Incontinent Bowel Movement?)
RS/6000 Running AiX 4.  The last trick will work on any system on which users
either by default have terminal writeability enabled, or can turn it on. (some
systems have it set up so users can't turn their writeability on (or can't do
it very easily.)) In theory, the second trick should work on almost ANY unix
machine, unless the admin has the audacity to disallow execution of things
such as chmod or vi.

Trick #1: Read other people's sent-mail.

This can be a fun trick.  It relies on the fact that the system admin guy
has NO clue what he's doing.  Actually, this little nasty has been overlooked
on many a system, even a few that i have access to, and I know there are more
of them out there.

Pine, a wonderful text mode e-mail program that is still widely used,
likes to keep things in "folders".  When a user writes an e-mail, a copy is
sent to the recipient of the e-mail, and a copy is stored in the "sent-mail"
folder under pine.  Typically, this "folder" is in the /mail subdirectory
under the user's home directory.  There are numerous ways of finding out
usernames that are on that system.  One way is just to run finger.  Jot
down all the usernames you see, and keep that as a reference.  If you do
this enough times, you might end up with a few hundred account names.  This
is all you really need.

Another way to get account names is by trying to list all subdirectories
sprouting from your parent directory.  Do the following from your home
directory:

cd
cd ..
ls

That might list all usernames.  If the system admin knows what he's doing, it
may not work.  Stick with things like the  who  and  finger  commmands to
find usernames.

To read their outgoign e-mail, get to your home directory by typing  cd  alone
on a line.  Type  pwd  ,which will tell you what directory you are in.  My
account on my main distro site is called "axon2017".  when i type pwd from my
home directory i get:

/homea/axon2017

Let's say that you want to read the sent e-mail from a person with the
username "bjones".  His sent-mail folder will be in the path of:

/homea/bjones/mail

(Just a note: Chances are your system won't have a "homea" directory, it may
be something like "home", or "usr", something like that possibly.)

The interesting thing about pine's e-mail "folders", is that the folder is
just all the messages put directly into one file all in a row.  So, you can
easily use vi, pico (blah), or cat to read the email.  Here is how i would
read bjones' sent-mail:

cd                                      'gets me back to my home directory
vi /homea/bjones/mail/sent-mail         'opens his sent-mail folder in vi

if you wanted to use cat, you could substitute the vi line with:

cat /homea/bjones/mail/sent-mail | more

the  | more on the end informs cat that you want the screen to pause when it
scrolls one screen.  To move to the next screen, just hit the space bar, or
hit q if you want to quit viewing it.

This bug is made possible because while the permissions on the mail sub-
directory are usually set to where normal users can't access it, the perms
on the actual files are not set to restrict viewing.  In most cases, the file
can't be altered, but you can download it via FTP, or save it to your home
directory.  of course this may be slightly suspicious.  If your system admin
likes to view history files, that might be a problem as well.  This makes a
perfect introduction to my next fun trick.


Trick #2: Changing the past!

Changing the past?  What in the world does that mean?  Well everything you
type under the shell in unix is logged (i DO so hope you know this much, but
if you didn't, it's time you not only learn, but time you learn how to change
what that log shows.  This really is a job for the VI editor.  Pico does not
work on the history file usually.  The file is called .sh_history, in each
user's home directory.  Since it starts with a dot, it will be hidden from the
LS command unless you use the -a flag.  I would venture a guess that this
file began as some sort of security measure, to monitor what people were doing
on the system, and keeping it somewhat hidden from prying eyes.  The only
problem with this is the fact that any efforts to edit it will end up being
appended to the end of the log file once your editor closes the file.  Talk
about "begging for attention"...that's a way to get it from your admin.

I've always thought shell scripts were useful.  A Shell script is exactly
the same as a DOS Batch File.  Each command you want to execute in the script
is put on its own line.  When the script is executed, it will run each line
sequentially.  We'll make a simple shell script in order to edit our history
file.  The thing is, we need to name this script the same as a normal unix
command.  I chose cls, which is not really a normal unix command, but some
UNIX's have a shell script that does the same thing.  CLEAR is the commmand
typically used to clear a screen.  Cls might seem like a typical error, when
an admin sees it in the logs.  This is the source code you need to store in
the file.  Use vi, Pico, or echo >> to do this.  I just used echo >> here's
my example.

source code:

#!/bin/ksh
#This Script Clears The Screen
vi .sh_history

This is all I did to make the file using echo >>:

echo "#!/bin/ksh" >> cls
echo "#This Script Clears The Screen" >> cls
echo "vi .sh_history" >> cls


the >> redirects the results of echo out to a file, in this case CLS, adding
the text to the end of the file.

If you are not very well-versed in UNiX yet, you may not realize that the
script you just made has to bbe made an executable.  In DOS, if a file has
a .COM, .EXE, or .BAT extension, it refers to it as executable.  In UNIX,
there really are no file extensions.  A period can be used in a filename, or
several periods.  You have to use the change mode command, called CHMOD to
make this file executable.

chmod 700 cls

No, 700 is not some magic code for "make it executable".  The first digit is
what access you have to the file, the second and third, you dont need to worry
about, because those are what access other people have to your file.  We set
these to 0, which means you are denying them any access.  7 makes the file
readable, writeable, and executable.

Now, when you type cls, your history file will appear on screen with the vi
editor.  I will NOT go over the whole vi editor command set with you, but I
will tell you enough to take lines out of your .sh_history file.

When in vi, use the arrow keys to get to the line(s) you wish to take out.
to delete a whole line, hit  <d> <d>  yes, that's right...hit the "D" key
twice.  make sure caps and shift are turned OFF!  Poof! the line is gone.
you can move to another line and use <d> <d> again and again.  To save the
file hit <:> <w> <!> <enter>.  Once the file is saved, hit <:> <q> and you
are back to the prompt.  Easy, huh?


Trick #3: Let's mess with someone's terminal!

This is a little more involved, and does not work at all unless someone else
is on the same system as you are, and has their terminal writeability enabled.
To see who is writeable, type  "who -w"  You will see a few fields, the only
ones we care about will be the login-name field, the terminal field, and the
field containing only + or - symbols.  If there are any + symbols, you are in
luck, for now you have someone to mess with.

If you want to just test this, then go to a computer lab or library where you
can use telnet on 2 computers side by side, and log in to the same host 2
times, once on either machine.  type  mesg y  at both of the unix prompts,
then find out which virtual terminals you are on (using the terminal field
of the who -w command) You will be interested mostly in the other one, the
one that you are next to, not the one that you are sitting and typing at.
once you find that virtual terminal, you are ready to go.  You will from now
on refer to that virtual terminal as /dev/pts/2  or whatever it is, even
though the terminal field only says pts/2, you need to refer to it with the
/dev/ in front of it.

Try clearing the other screen.  This is fairly simple.

clear > termpath

termpath will be the /dev/pts/2 or whatnot.  See, the output of any program
can be sent to any other virtual terminal that is writeable.  the greater-
than sign is used to REDIRECT the output.  You can run anything, and make the
other screen look exactly like yours would.  Things to try: redirecting a
pine session, redirecting output from various unix commands such as finger,
who, and even telnet.  Another possibility if you want to annoy, use cat to
read a binary file, then redirect the output to the terminal
(cat /bin/ksh > /dev/pts/2).  Oh the evil deeds you can persue...

Using this little ability to annoy someone to the point where they will close
their telnet connection to the host can open up other security holes, for
instance with proper timing and a lot of hard work, you can capture a log-in
session and snag passwords, however this is detailed in far too many cookbook
hacks that are available elsewhere, and begin to stray from the informative
nature of this publication, as its useage really can not be used for purposes
aside from obtaining passwords and logins (cool stuff but far outside the
scope that i wish to cover here)

Look for more Unix fun in future releases of HiR.